-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Make TypeId const comparable #142789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Make TypeId const comparable #142789
Conversation
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri Some changes occurred to the CTFE machinery Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
3cddd21
to
1fd7b66
Compare
This comment has been minimized.
This comment has been minimized.
It will be a while until I have the capacity to review a PR of this scale. Meanwhile, could you say a bit more about the architecture of the change? It seems you want for the "new kind of allocation" approach, but it's not clear from the PR description how exactly that shows up in Also, I am definitely not comfortable landing this by myself, I can only review the const-eval parts. Changing the representation of |
Some changes occurred in compiler/rustc_codegen_ssa |
Well, I got private feedback yesterday that instead of encoding a 16 byte value as an 8 byte pointer to the 16 byte value and an 8 byte hash, I should just do the thing where we split up type id internally into pointer sized chunks and codegen will make a hash out of it again. TLDR: no changes to runtime type id anymore in the latest revision of this PR. Only compile-time type id is now a bit funny |
I'm splitting unrelated parts out, so the high level feedback is already useful and I'll look for libs and codegen ppl to review the appropriate parts |
This comment has been minimized.
This comment has been minimized.
Make `PartialEq` a `const_trait` r? `@fee1-dead` or `@compiler-errors` something generally useful but also required for rust-lang#142789
Make `PartialEq` a `const_trait` r? ``@fee1-dead`` or ``@compiler-errors`` something generally useful but also required for rust-lang#142789
☔ The latest upstream changes (presumably #142906) made this pull request unmergeable. Please resolve the merge conflicts. |
b8a7a10
to
1c47a64
Compare
This comment has been minimized.
This comment has been minimized.
1c47a64
to
bcb4aa2
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Make TypeId const comparable This should unblock stabilizing const `TypeId::of` and allow us to progress into any possible future we want to take `TypeId` to. To achieve that `TypeId` now contains `16 / size_of<usize>()` pointers which each are actually just `size_of<usize>()` bytes of the stable hash. At compile-time the first of these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactor `TypeId` to any other scheme in the future without breaking anyone who was tempted to transmute `TypeId` to obtain the hash at compile-time. cc `@eddyb` for their previous work on #95845 (which we still can do in the future if we want to get rid of the hash as the final thing that declares two TypeIds as equal). * #77125 r? `@RalfJung`
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (448540b): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.7%, secondary 1.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.8%, secondary 1.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 462.82s -> 460.745s (-0.45%) |
Lol, seems it speeds up more benchmarks than it slows down. ;) I assume |
☔ The latest upstream changes (presumably #143434) made this pull request unmergeable. Please resolve the merge conflicts. |
ctfe improvements are just the opt of not creating an allocation anymore just to copy it and throw it away. The others are llvm opt changes that are probably unrelated. This is not used enough to cause compile time changes and we have no dedicated runtime benchmarks for it |
Makes sense. There is one unresolved comment still up, and the one I just commented on. I am not 100% confident in the GCC and cranelift changes; @bjorn3 @rust-lang/wg-gcc-backend would be good if you could take a look. This is a new "magic" kind of pointer where codegen should just ignore the |
a7888a7
to
58d86ec
Compare
clean up GVN TypeId test addresses rust-lang#142789 (comment) This is an attempt to clarify what this test is actually supposed to test and make it less dependent on `TypeId` internals (it now depends on the output of `type_name` instead). I verified that this version still miscompiles on `nightly-2025-02-11`. r? `@oli-obk` `@RalfJung`
clean up GVN TypeId test addresses rust-lang#142789 (comment) This is an attempt to clarify what this test is actually supposed to test and make it less dependent on `TypeId` internals (it now depends on the output of `type_name` instead). I verified that this version still miscompiles on `nightly-2025-02-11`. r? ``@oli-obk`` ``@RalfJung``
This should unblock stabilizing const
TypeId::of
and allow us to progress into any possible future we want to takeTypeId
to.To achieve that
TypeId
now contains16 / size_of<usize>()
pointers which each are actually justsize_of<usize>()
bytes of the stable hash. At compile-time the first of these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactorTypeId
to any other scheme in the future without breaking anyone who was tempted to transmuteTypeId
to obtain the hash at compile-time.cc @eddyb for their previous work on #95845 (which we still can do in the future if we want to get rid of the hash as the final thing that declares two TypeIds as equal).
const fn
type_id
#77125r? @RalfJung